Apparatuses for testing automatic control devices are known from a published product catalogue, “Catalog 2015/Embedded Success dSPACE”, which is available as a printed catalogue, is cited hereinafter quoting the reference number “P1”, and can be found on the internet at www.dspace.com/de/gmb/home/medien/product_info/catalog_contents.cfm. In particular, apparatuses and the components thereof are described on pages 296 to 331 and on pages 496 to 515 of P1 for the specified use. The cross-linking of the apparatuses can be carried out for example via Ethernet interface cards, such as in the above-mentioned product catalogue on pages 472 and 473. Such apparatuses can be configured as “HIL simulators”, the abbreviation “HIL” (hardware in the loop) referring to a closed control loop.
The automatic control devices mentioned at the outset are often referred to as control units, although the range of functions thereof generally goes beyond the “pure” open-loop control function in systems theory terms, and includes closed-loop control functions.
The first computer unit of the apparatus for testing, which comprises at least a first microprocessor, is provided and configured to execute a first model code which produces at least part of the plant simulation via the first microprocessor (“plant” as understood in the context of control engineering). Together with the hardware of the apparatus, the model code reproduces the technical environment of an electronic device or of a more complex technical system at least in part. Using the model code, the apparatus provides simulated sensor signals for the automatic control device, for example. Furthermore, the apparatus can be used, for example, as a controlled current sink for diverting an actuator current provided by the automatic control device.
HIL simulation is an international term, which is also used in particular in German-speaking countries, for a test method in which an “embedded system”, for example an automatic control device or a mechatronic module is connected via the inputs and outputs thereof to an adapted counterpart, for example an apparatus in the form of an HIL simulator, which apparatus is used to reproduce the actual environment of the embedded system. During testing of the embedded system, at least some of the input signals for the embedded system are thus provided by the HIL simulator, and at least some of the output signals of the embedded system are sent to the HIL simulator.
For example, using a model code of a plant model, which is executed on a single HIL simulator, the temporal behaviour of the environment of the system to be tested is reproduced. If for example an HIL simulator is intended to test an embedded system, in particular an automatic control device (often referred to as an ECU: “electronic automatic control device”, for short), then the HIL simulator is configured as an at least partial reproduction of the actual environment of the automatic control device. In this case, the HIL simulator can thus communicate with the control device via the inputs and outputs or bidirectional communication channels thereof and thus function as an adapted counterpart to the automatic control device.
The HIL simulation usually has to take place in real time. When simulating the technically relevant environment of the automatic control device, the simulated environment comprising the simulated plant (“plant” as understood in the context of control engineering), in particular such interactions of the automatic control device, which can recur in a later actual environment of the automatic control device, can be reproduced in an automated manner and/or in a predefined sequence. This has the advantage that a new development version of open-loop or closed-loop control software can be tested according to the same criteria as the previous version. Thus it can be demonstrated in detail whether an error has been resolved or not (retesting).
Tests on actual systems (for example on a braking system or an anti-slip system of a motor vehicle) can be greatly reduced through the tests on the HIL simulator and, in addition, system limits or limits on the controllability of the automatic control device and/or the plant can be determined without the actual system and the users thereof (e.g. cars and drivers) being placed at risk.
The HIL simulation is still only a simplification of reality and usually cannot completely replace the subsequent test on the actual system which usually follows, for example the test of the interaction of the automatic control device with the “real” plant of a controlled prototype and/or the test of the interaction of the automatic control device with a controlled standard product.
It is known to use a spatially distributed apparatus to test at least one electronic automatic control device, the apparatus comprising at least two separate computer units—for example at least two simulators which are at a distance from one another and are cross-linked. In the document “A Hardware-in-the-Loop Test Bench for the Validation of Complex ECU Networks”, J. Gehring, H. Schütte, dSPACE GmbH, page 3, FIG. 3 of the 2002 document, publication reference “SAE 2002 Word Congress Detroit, Michigan Mar. 4-7, 2002”, which was published in 2002 and is referred to below as P2, an apparatus is shown which is configured as a distributed HIL simulator and comprises a plurality of computer units which in this case are configured for example as a central unit, an engine, a transmission and a combined ESP suspension. The computer units are cross-linked to one another via an optical connection, i.e. a high-speed optical link. On the right-hand side of page 7, paragraph “Conclusion” in the second bullet point of said document, it is mentioned that requirements for an interprocessor communication may necessitate time stamping and automatic process synchronisation.
From the document “Hardware-in-the-Loop Technology Enabling Flexible Testing Processes”, Andreas Himmler, dSPACE GmbH, page 3, paragraph B., publication reference “51st AIAA Aerospace Sciences Meeting, 2013, Grapevine, Tex., USA”, which is referred to in the following as P3, it is known to provide a serial network called IOCNET, which builds on the physical layer of the Gigabit Ethernet, for HIL simulators, through which the interface cards provided for the input and output of signals and data, abbreviated to I/O cards, can exchange data both with one another and with the microprocessor card(s) in real time. For the exchange of data between the I/O cards and/or processor cards which are for example up to 100 meters apart, Gigalink modules can be used, as are shown for example in the above-mentioned document P1 on pages 355 and 361. As data transmission media between the I/O cards and/or processor card(s) which are for example 100 meters apart, a fibre-optic cable connection, referred to here as “optical media” or “fibre-optic cable”, is proposed in P3, page 3, paragraph B and in P1, page 349. The already mentioned network IOCNET provides a protocol which supports a time synchronisation, in particular for reading input signals at the interfaces of the I/O cards used; see optionally document P1, page 299 together with the drawing on the same page in this regard.
The above-mentioned cross-linking solutions using IOCNET for time synchronisation within an apparatus—in particular an HIL simulator—in order to test an automatic control device is in any case only provided for a distance between the computer units which exceeds 100 meters by only a negligible amount.